home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr48 / 386p_200.zip / 386POWER.TXT < prev    next >
Text File  |  1994-11-30  |  9KB  |  201 lines
  1. 386POWER 1.01 TECH REF
  2.  
  3. WHAT'S THIS ?
  4.  
  5. 386Power is a simple unified interface to DPMI and VCPI dos extender services.
  6. It kicks your program in 32bit protected mode and gives you an 
  7. application programmer interface similar to that of PMODE 386
  8. by Thomas "Tran" Pytel.
  9. Nothing strange, initially i started coding a library for PMODE386
  10. but after some troubles with things relating the dos-ext.
  11. i decided to make sort of dos extender on my own.
  12.  
  13. This documentation ...well i had not much time left...
  14. it will get better in future releases
  15.  
  16. After reading ALL THIS FILE (look in the end for some TECHNICAL things
  17. you have to absolutely know).
  18. look into TECH.DOC for a programmer reference and more info about
  19. the inner working of 386P.
  20.  
  21. For more info about the companion XGE code (graphics, sound, etc. etc.)
  22. look the other text files for an overview and
  23. into the .INC files or into the sorce code for deeper info.
  24. Look into EXAMPLES.DOC for the info needed to get fully running examples.
  25.  
  26. WHAT IT DOES:
  27. Well, the 386power module kicks your program in 32bit protected mode
  28. and allocates memory and segment descriptors for you, then it gives you a
  29. SIMPLE interface you can use to call dos/bios functions.
  30. The XGE (eXtended Game Engine) modules (read: all the other stuff)
  31. are a collection of things you may find useful if you wanna work
  32. in protected mode to devenlop your game engine.
  33.  
  34. You may wonder why i insist talking about game engines instead of "programs".
  35. The reason is simple: If you think to devenlop a brand new assembly program for
  36. every game you will make ... you are nuts.
  37. Instead identify the type of game you want to make
  38. (a boardagame with animations, a beat 'em' up, a shoot 'em' up, a simulator
  39.  etc. etc.), make a game engine for it, complete the g.e. with the graphics
  40.  the sound , the soundtrack and at last the finite state machines (actually
  41.  a bunch of lookup tables) you need to describe the game rules and
  42.  animations and LO! YOU GET A COMPLETE GAME!
  43. Then, if your game is successful you can quickly make a sequel, maybe
  44. enhancing a little the game engine, adding new graphics and new
  45. finite state machines for new rules and/or "actors".
  46. Else if it fails but you think the initial idea was correct, you will
  47. concentrate on the actual game coding (the g.e. is allright)
  48. cutting the devenlopement time.
  49.  
  50. FROM WHERE IT COMES FROM:
  51.  
  52. This code has been produced  following the information
  53. obtained from ...
  54.   a) DPMI 1.0 and 0.9 specs         (uploaded from Internet)
  55.   b) The Ralph Brown Interrupt list (uploaded from Internet)
  56.      Valuable source of informations for the VDS and VCPI specs
  57.   c) The PMODE386 dos extender by Thomas Pytel a.k.a. Tran from Renaissance
  58.      (i looked in pmode.doc and reverse engineered the source to understand
  59.       how to connect properly with  DPMI and VCPI, it's not as simple as
  60.       the technical documentation says. )
  61.      I even COPIED some chunks from PMODE source code. 
  62.      So i don't totally "own" 386Power code, but nor you neither Tran.
  63.   d) All the people that reported me bugs and program quirks
  64.      I cannot list them all , but the first one needs a special mention:
  65.      Alex Yu from Taiwan
  66.   
  67. WHO OWNS IT ?
  68.      As i said, 386Power code is not all mine, i've copied some algorithms
  69.      from PMODE dos-extender by Tran.
  70.      The XGE code instead is all mine.
  71.      What i own is the 386Power product name and big chunks of code
  72.      into it, if you use 386Power you HAVE to give credits to me 
  73.      (Lorenzo Micheletto) and to Tran (Thomas Pytel).
  74.      Simply do not remove the "diagnostic" messages and if you
  75.      put a "credits" screen on your program include me and Tran
  76.      and you are OK.
  77.      If you do this, you can freely use 386Power on anything you want
  78.      ( except viruses or trojan horses, i hate those losers that think
  79.       they are smart just because they can write such beginners stuff )
  80.      You can even alter the sources, but if you do this
  81.      you have to change the product name (but leave partial credits
  82.      to me and Tran) OR specify it is an altered version.
  83.      My numering procedure is as follows:
  84.      386P Rev. XX.YZW
  85.      Where XX is the revision major number
  86.             Y is the revision minor number
  87.             Z is the revision "minor bugfix" number
  88.             W is the revision "cosmetic update" number
  89.             
  90.      If you modify 386Power you have to add a "secondary revision" identifier
  91.      i.e.  if you modify   386P 01.020       
  92.            you can call it 386P 01.020:01.000
  93.            and "mark" your updates to the original code
  94.            in the second revision number.
  95.      Of course if you make radical alterations you'd better
  96.      change the product name to avoid confusion.     
  97.      
  98. WHAT'S PART OF
  99.  
  100. 386Power is part of the XGE (eXtended Game Engine)
  101. project i started 5 months ago, after i decided to move to extended mode
  102. for game devenlopement.
  103.  
  104. XGE consist of:
  105.  
  106. a) Public domain stuff
  107.  
  108.         386Power  Interface to DPMI or VCPI protected mode services.
  109.                   FLAT 386 programming model
  110.                   Automatic irq reflection under VCPI
  111.           
  112.         386File   Simple file i/o from protected mode.
  113.  
  114.         vdma      Virtual DMA support
  115.  
  116.         386Video  basic graphics functions
  117.         386mouse  basic mous efunctions
  118.         386joy    joystick
  119.         386keyb   "raw"keyboard support
  120.         386arg    command line scanner
  121.         386menu   full screen menu support
  122.  
  123.         PCX       PCX decoder.
  124.         Pix       Basic pixel and rectangle plotting under mode-x
  125.         Picture   Routines to handle linear bitmaps and
  126.                   Transparency-run-lenght-encoded sprites under mode-x
  127.         CharIO    Multicolor Character I/O u
  128.         Pattern   Tile handling
  129.           
  130. SOME THINGS YOU'D BETTER REMEMBER:
  131.  
  132. DPMI 
  133.  
  134. DPMI is a strange beast, it virtualize things, so some things
  135. that under VCPI run as expected becomes quite fuzzy under ring 3.
  136.  
  137. Minimize OUT and privileged instructions to avoid problems
  138. and always keep in mind you are running on (badly) virtualized hardware.
  139. When running under DPMI , 386P tries to allocate all lockable memory
  140. (so you can use extended memory for irq code/data and avoid disk swapping).
  141. IF YOU USE EXTENDED MEMORY FOR STORING IRQ CODE/DATA
  142. YOU'D BETTER LOCK THE CHUNKS OF MEMORY YOU ABSOLUTELY NEED.
  143.  
  144. INTERRUPT VECTORS
  145.  
  146. Under 386Power you have THREE SETS of interrupt vectors
  147. The V86 interrupt table
  148. The Protected Mode interrupt table
  149. The OldInt (OLD V86 INTerrupt) table 
  150.  
  151. OldInt gets initialized when 386P starts
  152. with the vectors found in the dos interrupt table (the V86 interrupt table)
  153.  
  154. When you call int 33h from protected mode you actually call
  155. AN INTERRUPT VECTOR IN THE OldInt TABLE !!!
  156.  
  157. If an IRQ happens while in 32bit mode, the protected mode table is used.
  158. If an interrupt happens in V86 mode, and you run under DPMI, the irq
  159. is reflected to protected mode, else under VCPI the real mode
  160. handler is called.
  161.  
  162. Here comes the OldInt table.
  163.  
  164. Every IRQ not supported in protected mode gets redirected to the
  165. OldInt table (initially equivalent to the V86 table).
  166.  
  167. If you change the ISR from prot. mode
  168. you don't have to save the old V86 MODE irq
  169. (it is already into the OldInt table, and it will be restored into
  170.  the V86 table at program termination).
  171.  
  172. What's more, from inside a protected mode irq handler you can call
  173. the "old" real mode irq using int 33h (from prot. mode)
  174. without having to worry about "infinite irq loops".
  175.  
  176. Foggy, isn't it ? We'll the first time you have to chain&bypass
  177. an ISR you'll be happy there are 3 int tables!
  178.  
  179. PARAMETER PASSING CONVENTION:
  180. Parameters for procedures in the companion XGE assembly code files
  181. are assigned in the following order
  182. EDI = pointer to destination OR base offset of destination screen
  183. ESI = pointer to source data (usually bitmap data)
  184. EAX = x position OR 1st parameter
  185. EDX = y position OR 2nd parameter
  186. ECX = x-width    OR 3rd parameter
  187. EBX = y-width    OR pointer to characters OR 4th parameter
  188. EBP = 5th parameter
  189.  
  190. The reason i use registers is that xge code mostly interract with hardware
  191. or executes "basic" operations, usually it does not call other subfunctions
  192. so it is faster is all the parameters it need are already into registers.
  193.  
  194. INT 32h FROM REAL MODE:
  195. Calling int 32h from real mode the flag register WON'T BE UPDATED
  196. by the result of the function called, nor the virtual registers will be
  197. passed.
  198. The int 32h system must be used only to pass control to prot. mode
  199. code, the less you use it, the better.
  200.  
  201.